DESCRIPTION 

PLAYBACK APPARATUS FOR PERFORMING APPLICATION-SYNCHRONIZED 

PLAYBACK 

5 TECHNICAL FIELD 

The present invention belongs to the technical field 
of digital streams and application-synchronized playback. 

BACKGROUND ART 

10 Application-synchronized playback is technology for 

playing digital streams while at the same time running Java 
(registered trademark) applications in a playback apparatus 
or the like for playing video, and belongs to a technical 
field that will attract a great deal of attention in consumer 

15 device manufacturing from now on. Applications and digital 
streams for synchronizing are associated with one another 
in units of playback called "titles". The following describes 
a conventional playback apparatus* A conventional playback 
apparatus is constituted from a virtual filesystem unit, a 

20 module manager, a playback unit, and a platform unit. 

The virtual filesystem unit manages a plurality of 
recording media accessible by the playback apparatus such 
as optical recording media (e.g. DVD-ROM, BD-ROM, the latter 
of which is described later by way of example) and magnetic 

25 recording media (e.g. hard disk), and generates package 
information integrally showing the recorded content of these 
recording media , 

Each piece of package information, called a virtual 
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package, is submitted in the playback/execution of digital 
streams and application programs (hereinafter simply 
"applications") recorded on these recording media just as 
if they were actually recorded in a single package* 
5 The module manager selects one of a plurality of titles 

as a current title. 

The playback unit plays a digital stream {i.e. recorded 
on an optical or magnetic recording medium) constituting the 
current title from digital streams shown by the package 
10 information. 

The platform unit runs an application (i.e. recorded 
on an optical or magnetic recording medium) constituting the 
current title from applications shown by the package 
information. 

15 According to the above structure, digital streams and 

applications recorded on different recording media such as 
BO-ROM and hard disk can be treated as a single (virtual) 
package, and the playback apparatus is able to realize 
playback controls in units of titles. 

20 Titles in the above structure target not only digital 

streams recorded on BD-ROM for playback but also digital 
streams recorded on hard disk. Since hard disk is a rewritable 
recording medium, the compositional elements of a title may 
possibly be replaced partway through playback in cases such 

25 as when package information is newly generated using a newly 
acquired digital stream. 

Such a replacement is largely thought to bring about 
situations that are difficult to restore such as video 



blackout during playback resulting from abnormal operation 
of the playback unit. 

The replacement of the playback object partway through 
playback can be anticipated if the playback unit in the 
5 playback apparatus sequentially checks the sameness of 
elements such as streams and playback control information 
targeted for playback. However, given the diverse types of 
information that require checking, this places a great burden 
on the playback unit. 

10 To be absolutely sure of the device's stable operation, 

it is desirable to reboot the device itself when there has 
been a change in the recorded content on hard disk, as you 
would when installing software. However, given that 
rebooting the device takes anywhere from a few seconds to 

15 a few minutes processing time, this is not something that 
the user undertakes lightly. 

DISCLOSURE OF THE INVENTION 

An object of the present invention is to provide a 
20 playback apparatus capable of realizing stable playback even 
if there is a change in the playback object. 

To resolve the above problems, the present invention 
is a playback apparatus that plays a digital stream in 
conjunction with an application, and includes a package 
25 management unit operable to generate package information by 
merging files recorded on a first recording medium and a 
second recording medium, in accordance with merge management 
information, and a selection unit operable to detect a 



plurality of playable titles from the package information/ 
and select one of the detected titles as a current title- 
After the application requests the package management unit 
to update the merge management information, by specifying 
5 new merge management information, the package management 
unit changes a file referenced from the newly specified merge 
management information to read-only before updating the 
package information, and at a point at which digital stream 
playback stops due to a current title change by the selection 

10 unit, the package management unit generates new package 
information by combining files recorded on the first and 
second recording media, in accordance with the newly 
specified merge management information- 

The present invention, as a result of having the above 

15 structure, guarantees that in the case of an application 
requesting the package management unit to update the merge 
management information by specifying new merge management 
information, the content of a file referenced from the newly 
specified merge management information is not altered from 

20 the time the update request is made until the when the current 
title is changed, since the package management unit sets the 
file referenced from the newly specified merge management 
information to read-only before updating the package 
information. Also, by updating package information at the 

25 point at which digital stream playback is stopped due to a 
current title change, abnormal operation of the playback 
apparatus is not brought about even when, for instance, the 
digital stream or application targeted for 



playback/execution is replaced as a result of updating. 

Thus, the breadth of expression with movie works is 
expanded since playback controls can be realized by 
dynamically merging files recorded on both first and second 
5 recording media while securing the stable operation of the 
playback apparatus. 

Here, the package management unit may be configured to 
update package information if information in a permission 
tag of an application that requested the updating indicates 
10 that the application has been assigned the right to update 
the package information, and to reject the update request 
and perform exception processing if this information 
indicates that the right to update has not been assigned. 

This structure enables the updating of package 
15 information requested by unauthorized applications to be 
prevented, 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig.l is a system diagram; 
20 Fig, 2 shows an internal structure of a BD-ROM 100; 

Fig. 3 systematically shows how a file with the extension 
"m2ts" is structured; 

Fig. 4 shows the structure of PL information; 

Fig. 5 shows the relation between an AVClip and a PL; 
25 Fig, 6 shows batch specification using four 
Clxp_Inf ormation_f ile_names; 

Fig. 7 shows an internal structure of PLMark information; 

Fig, 8 shows chapter definitions using PLMarks; 



Fig r 9 shows an internal structure of SubPath information; 
Fig. 10 shows sync specification and playback interval 

definitions on a SubClip time axis; 
Fig.llA shows program data housed in an archive file; 
5 Fig.ilB shows an internal structure of a class file; 
Fig. 12 shows an internal structure of a BD-J object; 
Fig, 13 shows an internal structure of INDEX. BDMV; 
Fig. 14 shows a directory structure in local storage; 
Fig, 15 shows the kinds of playlist playback time axes defined 
10 by PL information stored in local storage; 

Fig . 16A shows an AVClip stored on BD-ROM and a Java 

application and AVClips stored in local storage; 
Fig,16B shows the Java application and AVClips#l-#4 being 

treated as a single title; 
15 Fig. 17 shows an exemplary internal structure of a merge 

management information file; 
Fig, 18 shows the hardware configuration of a playback 

apparatus; 

Fig. 19 depicts elements composed of hardware and software 
20 stored on instruction ROM 21 rearranged in a layer 

structure; 

Fig.,20 shows an internal structure of a Java virtual machine 
30; 

Fig. 21 shows a status transition resulting from title 
25 changes; 

Fig. 22 shows an exemplary creation of virtual package 

information by a virtual filesystem unit 38; 
Fig.23A shows a time axis for an entire disc; 
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Fig.23B shows the structure of the time axis for the entire 

disc- 
Fig. 24 is a flowchart of download processing by a Java 

application; 

5 Fig. 25 is a flowchart of an update "preparing" procedure; 
Fig. 26 is a flowchart of a virtual package "updating" 
procedure; 

Fig. 27 is a flowchart of processing by a module manager; 
Fig, 28 is a flowchart of a PL playback procedure; 
10 Fig. 29 shows how virtual package information is updated 
during a title change; 
Fig. 30 shows a Java application sending a current merge 

management information file to a server; 
Fig, 31 shows a Java application downloading content files, 
15 a new merge management information file, and a new 

signature information file; 
Fig. 32 shows a Java application making an update request to 

virtual filesystem unit 38; 
Fig -33 shows the replacement of merge management and 
20 signature information files, and the mapping of content 

files; 

Fig,34A is a flowchart of processing by a playback control 
engine when suspending playback of the current title 
after a title call; 
25 Fig.34B is a flowchart of processing by the playback control 
engine when resuming playback of the original title 
after playback of the called title has ended; 

Fig. 35 shows a merge management information file in an 



embodiment 3; 

Fig. 36 shows a Java application pertaining to embodiment 3 

requesting the update of a virtual package; 
Fig. 37 shows an exemplary additional contents list displayed 

to the user by a resident application using a merge 

management information file; 
Fig. 38 is a flowchart of the processing flow pertaining to 

embodiment 3 from the loading of a BD-ROM until playback; 
Fig -39 shows a valid interval being specified when a virtual 

package update is requested; 
Fig. 40 is a flowchart of the processing flow pertaining to 

an embodiment 4 from the loading of a BO-ROM (or 

rebooting of the playback apparatus) until playback; 
Fig, 41 shows permission request files being used to screen 

virtual package update requests; 
Fig. 42 shows access restrictions imposed on a directory in 

local storage targeted for merging; 
Fig. 43 shows both Java applications whose lifecycle is 

limited to a single title and Java applications whose 

lifecycle extends over a plurality of titles; 
Fig. 44 shows processing performed on a title-unbound 

application when a virtual package is updated during 

a title change; 
Fig, 45 is a flowchart of title change processing that takes 

title-unbound applications into consideration; and 
Fig. 46 is a flowchart of virtual package updating following 

a change in an INDEX. BDMV file. 
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BEST MODE FOR CARRYING OUT THE INVENTION 

Embodiment 1 

The following describes embodiments of recording media 
pertaining to the present invention. Firstly, a form of use 
5 out of the forms of the implementation of a playback apparatus 
pertaining to the present invention is described. Fig.l shows 
an exemplary form of use of a playback apparatus pertaining 
to the present invention. In Fig.l, a playback apparatus 
pertaining to the present invention is a playback apparatus 
10 200. Playback apparatus 200 is submitted for use in supplying 
movie works in a home theater system composed of a playback 
apparatus 200, a remote control 300, and a television 400, 
for example. 

An exemplary form of use of a playback apparatus 
15 pertaining to the present invention is as described above. 
Described next is a recording medium targeted for playback 
by a playback apparatus pertaining to the present invention. 
In the given example, the recording medium played by a 
playback apparatus pertaining to the present invention is 
20 a BD-ROM 100 (optical recording medium). Fig. 2 shows an 
internal structure of BD-ROM 100. 

BD-R0M 100 is shown at the 4th tier in Fig, 2, while a 
track on the BD-ROM is shown at the 3rd tier. The track 
depicted in Fig, 2 results from a track spiraling from the 
25 inner circumference to the outer circumference of the BD-ROM 
having been drawn out to the sides. This track consists of 
a lead-in area, a volume area, and a lead-out area. The volume 
area in Fig. 2 has a layered structure made up of a physical 



layer, a filesystem layer, and an application layer. 
Expressing the application format of the BD-ROM using a 
directory structure gives the 1st tier in Fig* 2. A BDMV 
directory is placed under a ROOT directory at the 1st tier 
5 in the BD-ROM. 

An INDEX . BDMV file is disposed in the BDMV directory , 
and under the BDMV directory exist five subdirectories known 
as a PLAYL1ST directory, a CL1P1NF directory, a STREAM 
directory, a BDJA directory, and a BDBJ directory, 
10 The STREAM directory stores a file forming the main 

digital stream, the extension >v m2ts" being assigned to this 
file (00001. m2ts) . 

In the PLAYLIST directory exists a file (00001, mpls) 
with the extension "mpls". 
15 In the CLIPINF directory exists a file (00001 .dpi) with 

the extension u clpi". 

In the BDJA directory exists a file (OOOOl.jar) with 
the extension "jar". 

In the BDBJ directory exists a file {00001. bdbj) with 
20 the extension "bdbj", 

These files are described next. 

AVClips 

The file with the extension "m2ts" (00001. m2ts) is 
25 described firstly. Fig . 3 systematically shows how a file with 
the extension n rn2ts" is structured. This file stores an 
AVClip. The AVClip (middle tier) is constituted by 
multiplexing TS packets resulting from the conversion of a 
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video stream composed of a plurality of video frames 
(pictures pjl, pj2, pj3) and an audio stream composed of a 
plurality of audio frames (upper 1 st tier) firstly to PES 
packets (upper 2 nd tier ) and then to TS packets (upper 3 rd tier) 

5 and the conversion of a subtitle presentation graphics 
(P-graphics or PG) stream (lower 1 st tier) and a dialogue 
interactive graphics (X-graphics or IG) stream (lower I st 
tier) to TS packets {lower 3 rd tier) in the same manner. 
Apart from the AVClip obtained through multiplexing as 

10 shown in Fig, 3, there also exist AVClips that do not result 
from multiplexing. These are called SubClips, and include 
AVClips constituting an audio stream, a graphics stream, or 
a text subtitle stream (TextST stream) etc- 

15 Clip Information 

The file with the extension "dpi" (00001. clpi) is a 
piece of clip information corresponding to an AVClip. Clip 
information, being management information, contains an 
EP__map showing the head location of a GOP and information 

20 such as the encoding format, frame rate, bit rate and 
resolution etc, of streams in the AVClip, 

PL information 

The file with the extension n mpls" (00001. mpls) stores 
25 PlayList (PL) information. PL information defines a playlist 
by referring to AVClips. Fig. A shows the structure of PL 
information, which, as shown on the left side of the diagram, 
is constituted from MainPath information, PLMark information, 



and SubPath information. 

MainPath information "MainPath { ) " is composed of 
Playltem information "Playltem () ", as indicated by the 
arrows mpl. A playitem is a playback interval defined by 

5 specifying an In_time and an Out_time on one or more AVClip 
time axes. A playlist composed of a plurality of playback 
intervals is defined by the placement of plural pieces of 
Playltem information. The arrows mp2 in Fig. 4 shows a close 
up of the internal structure of Playltem information. As 

10 shown in Fig. 4, Playltem information is composed of an 
Injiime, an OutJ:ime, and a Clip_Inf ormation_£ ile_name 
showing a corresponding AVClip. Fig. 5 shows the relation 
between an AVClip and a PL. The 1^ tier shows the time axis 
of the AVClip, while the 2 nd tier shows the time axis of the 

15 PL. The PL information includes three pieces of Playltem 
information (PlayItems#l-#3) , with three playback intervals 
being defined by the I retimes and Out_times of Playltems#l, 
#2 and #3, A different time axis to the AVClip is defined 
when these playback intervals are arranged in line. This is 

20 the PL time axis shown at the 2 nd tier. Defining a different 
time axis to the AVClip is thus enabled by the definitions 
in the Playltem information. 

As a rule, one AVClip is specified at any one time, though 
batch specification of a plurality of AVClips is also 

25 possible. Batch specification of AVClips is performed using 
Clip_Information_f ile_names in Playltem information. Fig. 6 
shows the batch specification of AVClips using four 
Clip_Information_file_names. The 1 st to 4 th tiers in the 



diagram show four AVClip time axes (time axes of 
AVClips#l-#4 ) , while the 5 th tiers show the PL time axis. Four 
time axes are specified with these four 
Clip__Inf ormation_f ilejnarnes included in Playltem 

5 information. This allows four alternatively playable 
playback intervals to be defined by In_times and Out_times. 
As a result, an interval composed of plural piece of 
switchable angle video {so-called multi-angle interval) is 
defined on the PL time axis, 

10 PLMark information "PLMarkO" specifies an arbitrary 

interval on a PL time axis as a chapter. Fig, 7 shows the 
internal structure of PLMark information, which includes a 
ref_to_Play!tem_Id and a Mark_time_stamp, as indicated by 
the arrows pml. Fig, 8 shows the definition of chapters using 

15 PLMarks. The 1 st tier in Fig. 8 shows the AVClip time axis, 
while the 2 nd tier shows the PL time axis- The arrows pkl and 
pk2 in Fig .8 show the specification of a playitem 
(ref_to_Play!tem_Id) and a point in time (Mark_time_stamp) 
in PLMarks. Three chapters (ChaptersttlHf 3) are defined on 

20 the PL time axis as a result of these specifications. This 
completes description of PLMarks. 

SubPath information is described next. 
SubPath information "SubPathO" defines one or more 
playback intervals by specifying an In_time and an Out_time 

25 on a SubClip time axis, and has the internal structure shown 
in Fig. 9, SubPath information is composed of SubPlayltem 
information "SubPlayltem { } " as indicated by the arrows shl. 
In the close up marked by the arrows sh.2 t SubPlayltem 
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information is composed of a Clip_Inf ormation_f ile_name, an 
In_time, an Out_time, a Sync_Playltem_Id, and a 
Sync_Start_PTS_of_PlayItem. In__times and Out_times on the 
SubClip time axis are specified using 

5 Clip_information_f ilejiame, In_time, and Out_time included 
in SubPlayltern information, Sync_PlayItem_Id and 
5ync_Start__PTS_of_PlayItem are for synchronizing playback 
intervals on the SubClip time axis with the PL time axis. 
This allows processing on both the SubClip time axis and the 

10 PL time axis to proceed in sync with one another. 

Fig. 10 shows sync specification and the definition of 
playback intervals on the SubClip time axis. The 1 st tier in 
Fig. 10 shows the PL time axis, while the 2 nd tier shows the 
SubClip time axis. The SubPlayltern. In_time and 

15 SubPlayltern. Out_time in Fig, 10 show respectively the start 
and end of a playback interval. Thus it is apparent that a 
playback interval is also defined on the SubClip time axis. 
Sync_PlayItem_Id marked by the arrow Snl shows the sync 
specification of a playitem, while 

20 Sync_Start_PT5_of_PlayXtem marked by the arrow Sn2 specified 
a point during the playitem on the PL time axis. 

A feature of PL information in BD-ROM is that it makes 
possible the definition of multi-angle intervals that enable 
AVClips to be switched and sync intervals that enable AVClips 

25 and SubClips to be synchronized. Clip information and PL 
information are classified as "static scenarios". 

The following describes "dynamic scenarios". Here, 
"dynamic 7 ' refers to the fact that the content of playback 



controls changes due to user key events and status changes 
in playback apparatus 200 etc. With BD-ROM, playback controls 
can be described using the same description as Java 
applications. That is, with BD-ROM, Java applications act 
5 as dynamic scenarios. 

Java Applications 

The following describes Java applications. A Java 

application is composed of a one or more xlet programs loaded 
10 in a heap area (also called working memory) of a virtual 

machine. An application is constituted from the xlet programs 

loaded in working memory as well as data , The Java application 

structure is as described above. 

An actual Java application is the Java archive file 
15 (00001, jar) stored in the BDJA directory under the BDMV 

directory in Fig* 2. Java archive files are described below 

with reference to Fig, 11. 

Java Archive Files 

20 The Java archive file (00001. jar in Fig. 2) is a 

collection of one or more class files and data files etc. 
Fig. 11A shows programs and data collected in the archive file. 
The data in Fig.llA is a plurality of files collected by a 
Java archiver and arranged into the directory structure shown 

25 within the frame. This directory structure consists of a Root 
directory, a Java directory, and an image directory, with 
a common. pkg file, class files (aaa, class, bbb. class}, and 
a menu, jpg file being placed within respective directories. 



The Java archive file is the result of the Java archiver having 
collected these files together. The class files and data are 
expanded when read from BO-ROM to a cache, and treated in 
the cache as a plurality of files existing in directories. 

5 The five-digit numerical value "00001" in the filename of 
the Java archive file shows the identifier (ID) of the Java 
archive file, and the BD-J object uses this value to refer 
to the Java archive file. By referring to this numerical value 
in the filename when a Java archive file has been read to 

10 the cache, it is possible to extract data as well as programs 
constituting arbitrary Java applications. 

The class files (aaa. class, bbb. class) in Fig.llA 
correspond to the above xlet programs* Playback procedures 
in an operating mode (BD-J) supported by the Java platform 

15 are defined using xlet programs (i.e. instances) of these 
class files. An xlet program is a Java program capable of 
using a Java media framework (JMF) interface, and performs 
processing based on key events in accordance with JMF etc. 
Furthermore, xlet programs can also execute procedures 

20 for accessing websites and downloading contents. This 
enables playback of original works created by mixing 
downloaded contents with playlists. 

The class file of an xlet program is described next. 
Fig. 1 IB shows the internal structure of a class f ile . As shown 

25 in Fig.llB, this class file, similar to a normal class file, 
is composed of a constant pool, an interface, and methods 
1, 2, 3 ... n. The methods in a class file include those 
(EventListeners) that are triggered by preregistered key 



events and those for calling Application Programming 
Interface (API) functions in playback apparatus 200. 
Computation procedures and the like in these methods are 
described by employing local variables allocated to a given 

5 method and arguments occurring when the method is called. 
A Java archive file is as described above. 

The file with the extension "bdbj" is described next. 
This file (00001. bdbj) stores a BD-J object, A BD-J object 
is information defining a title by associating AVClips 

10 defined in PL information with applications. Fig. 12 shows 
the internal structure of a BD-J object. The BD-J object shows 
an application management table and a PL information 
reference value. The application management table shows Java 
applications whose lifecycle is the title defined by the BD-J 

15 object through enumerating the ID of individual Java 
applications (application IDs) and the IDs of the Java 
archive files belonging to particular applications. In other 
words, each application is constituted from one or more Java 
archive files. 

20 The PL information reference value shows PL information 

to be played when the title is started. 

The file with the extension ' x bdbj" is as described above. 
The INDEX. BDMV file is described next. 
INDEX. BDMV is management information relating to the 
25 entire BD-ROM. This file contains information such as 
organization IDs identifying the providers of movie works 
and disc IDs allocated to individual BD-ROMs provided by the 
providers. A disc is uniquely recognized in the playback 



apparatus by firstly reading INDEX > BDMV after the disc has 
been loaded. INDEX + BDMV may additionally include a table that 
maps a plurality of playable titles in BO-ROM to BD-J objects 
defining individual titles. The following describes the 
5 types of titles recordable to BD-ROM, which include a 
FirstPlayTitle, a TopjmenuTi tie, and Titles#l-#3, 

FirstPlayTitle is charged with playing a dynamic 
trademark of a BD-ROM when the BD-ROM is loaded before doing 
anything else, FirstPlayTitle thus realizes the practice of 
10 playing a dynamic trademark symbolizing the creator and/or 
distributor of a movie work when a BD-ROM is loaded . 

Top_menuTitle is composed of AVClips and applications 
for playing the menu positioned at the very top of the menu 
hierarchy in a BD-ROM. 
15 Titlesttl, #2 and #3 correspond to general movie works. 

In other words, INDEX * BDMV shows the correspondence of 
FirstPlayTitle, Top_menuTitle and Titles#l-#3 with 
individual BD-J objects. 

Fig. 13 shows the internal structure of INDEX . BDMV . This 
20 files shows the correspondence of FirstPlayTitle information, 
Top_menuTitle information, Title* 1 information, Title#2 
information, and Title#3 information with title IDs and BD-J 
objects defining these titles. BD-J objects defining the 
titles can be identified using the title information, while 
25 PL information and applications for synchronizing can be 
derived from these BD-J objects. This completes description 
of BD-ROM. 

BD-ROM is not the only recording media targeted by a 
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playback apparatus pertaining to the present invention. 

A hard disk (local storage) integral to the playback 
apparatus is also targeted during playback. The following 
describes data recorded in local storage. 

5 Fig. 14 shows a directory structure in local storage. 

In this directory structure, a subdirectory u organization#l" 
is located under a ROOT directory, and under this are the 
subdirectories "discttl" and u disc#2'\ The organization*! 
directory is allocated to a specific provider of movie works. 

10 The disc#l and disc#2 directories are allocated to different 
BD-ROMs provided by each provider. The organization ID and 
disc ID shown in the INDEX, BDMV file in respective BD-ROMs 
are employed in these directory names. 

Providing directories that correspond to BD-ROMs in 

15 directories corresponding to specific providers allows 
downloaded data relating to individual BD-ROMs to be stored 
separately. Under these subdirectories are stored PL 
information, clip information, and AVClips, similar to what 
is stored on BD-ROM. There also additionally exist a Java 

20 archive file, a BD-J object, a merge management information 
file, and a signature information file. 

In comparison to PL information on a BD-ROM, which refers 
only to AVClips on the BD-ROM, PL information in local storage 
includes information that refers to both AVClips on BD-ROM 

25 and in local storage; that is, PL information newly added 
as a virtual package, a specific example of which is PL INFO#2 
in Fig. 14, 

Here, PL information in local storage is constituted 
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from four pieces of Playltem information (Playltem 
information#l-#4 ) . This PL information can, in the case of 
the head piece (Playltem inf ormation#l) referring to clip 
information on BD-ROM and the remaining three pieces 

5 (Playltem inf ormation#2-#4 ) referring to clip information 
in local storage, define a single stream sequence from the 
AVClips on BD-ROM and in local storage, as shown in Fig, 15. 

Fig, 15 shows the kinds of playlist playback time axes 
defined by PL information stored in local storage- The 1 st 

10 tier shows the playback time axis of an AVClip#l stored on 
BD-ROM, while the 2 nd tier shows the playback time axis of 
a playlist defined in PL information stored in local storage. 
The 3 rd , 4 th and 5 th tiers show respectively the playback time 
axes of AVClips#2, #3 and #4 stored in local storage. 

15 In the case of Playltem inf ormation#2, #3 and #4 

specifying AVClips#2, #3 and #4 as playback intervals, the 
PL information in local storage is able to define both AVClips 
on BD-ROM and in local storage as a single stream sequence. 
As illustrated above, AVClips on BD-ROM and in local 

.20 storage can be defined as a single stream sequence, and by 
merging this stream sequence with applications on BD-ROM or 
in local storage, a single title can be constituted from 
AVClips and from applications recorded on BD-ROM or in local 
storage- In the case of AVClip#l being recorded on BD-ROM, 

25 and AVClips#2 to #4 and a Java application being recorded 
in local storage as shown in Fig.l6A, these AVClips and the 
Java application can, as shown in Fig.lGB, be treated as a 
single title, 
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Merge management information is described next. Merge 
management information uniquely shows all of files in the 
discs #1 and #2 directories in local storage that constitute 
a virtual package, and is stored in a prescribed file 

5 (hereinafter "merge management information file")- Fig, 17 
shows an exemplary internal structure of a merge management 
information file. A merge management information file is 
composed of storage location information for each file in 
local storage constituting a virtual package, Storage 

10 location information is composed of identifiers for 
accessing respective files as a virtual package and file 
paths indicating the storage locations of respective files 
in local storage. 

Signature information files are described next. A 

15 signature information file shows the electronic signature 
of a provider on a merge management information file. The 
electronic signature generally employed is obtained by 
computing a hash value for information that requires 
tamper-proofing and encrypting the hash value using some sort 

20 of secret key. 

This completes description of local storage. 
The following describes an embodiment of a playback 
apparatus pertaining to the present invention. Fig, 18 shows 
a hardware configuration of the playback apparatus. The 

25 playback apparatus is constituted from a BD-ROM drive 1, a 
read buffer 2, a demultiplexer (demux) 3, a video decoder 
4, a video plane 5, a presentation graphics (P-graphics) 
decoder 6, presentation graphics (P-graphics) plane 7, a 



composition unit 8, a font generator 9, an interactive 
graphics (I-graphics) decoder 10, a switch 11, an interactive 
graphics (1-graphics) plane 12, a composition unit 13, a 
color lookup table (GLUT) unit 14, a color lookup table (CLUT) 
5 unit 15, an audio decoder 16, a network device 17, a local 
storage 18, a read buffer 19, a demultiplexer (demux) 20, 
an instruction ROM 21, a user event (UE) processing unit 22, 
a player status register (PSR) set 23, a central processing 
unit (CPU) 24, a scenario memory 25, a local memory 26, and 
10 a switch 27. 

The elements (BD-ROM drive 1 - audio decoder 16) 
pertaining to playback of AVClips recorded on BD-ROM 100 are 
described firstly • 

BD-ROM drive 1 loads/ejects BD-ROMs, and accesses 
15 BD-ROM 100, 

Read buffer 2 is a first-in first-out (FIFO) memory in 
which transport stream (TS) packets read from BD-ROM 100 or 
local storage 18 are stored on a first-in first-out basis. 

Demux 3 reads TS packets from read buffer 2 and converts 
20 these TS packets to packetized elementary stream (PES) 
packets. PES packets having packet identifiers (PIDs) set 
by CPU 24 are then output to one of video decoder 4 , P-graphics 
decoder 6, I-graphics decoder 10, and audio decoder 16. 

Video decoder 4 decodes PES packets output from demux 
25 3 to obtain pictures in uncompressed format, and writes these 
pictures to video plane 5, 

Video plane 5 is for storing uncompressed pictures, A 
plane is a memory area in a playback apparatus for storing 



one screen worth of pixel data. Video plane 5 has a 1920 * 
1080 resolution, with stored picture data being constituted 
from pixel data expressed by 16-bit YUV„ In video plane 5, 
playback video in a video stream can be scaled per frame. 

5 Scaling involves changing playback video per frame to either 
1/4 (quarter) or 1/1 (full-scale) of the entire video plane 
5, Scaling is executed in BD-J mode in accordance with 
instructions from CPU 24 , enabling screen production whereby 
the playback images of video streams are relegated to a corner 

10 of the screen or projected over the whole screen. 

P-graphics decoder 6 decodes P-graphics streams read 
from BD-ROM and writes the uncompressed graphics to 
P-graphics plane 7. Subtitles appear on screen as the result 
of a graphics stream being decoded. 

15 P-graphics plane 7, being a memory with room for one 

screen worth of data, is able to store one screen worth of 
uncompressed graphics. This plane has a 1920 * 1080 
resolution, with pixels of the uncompressed graphics in 
P-graphics plane 7 being expressed by 8-bit index color . 

20 Uncompressed graphics stored in P-graphics plane 7 are 
submitted for display by converting the index colors using 
a GLUT. 

Composition unit 8 composites uncompressed picture data 
stored in video plane 5 with the stored content of P-graphics 
25 plane 7. 

Font generator 9 uses a character font to expand text 
code included in TextST streams in a bitmap, and writes the 
expanded code to P-graphics plane 7, 
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I-graphics decoder 10 decodes I-graphics streams read 
from BD-ROM or local storage 18 in DVD-like mode, and writes 
the uncompressed graphics to 1-graphics plane 12. 

Switch 11 selectively writes one of a font sequence 
5 generated by font generator 9 and graphics resulting from 
the decoding by P-graphics decoder 6 to P-graphics plane 7 , 

1-graphics plane 12 is written with uncompressed 
graphics resulting from the decoding by I~graphics decoder 
10. Characters and graphics drawn by an application are 
10 written into I-graphics plane 12 in BD-J mode using aRGB full 
color - 

Composition unit 13 composites the storage content of 
I-graphics plane 12 with composite images output from 
composition unit 8 (i.e. composition of uncompressed picture 

15 data and storage content of P-graphics plane 7) . This 
compositing enables characters and graphics written to 
I-graphics decoder 10 by an application to be overlaid on 
uncompressed picture data and displayed, 

CLUT unit 14 converts index colors in uncompressed 

20 graphics stored in video plane 5 to Y/Cr/Cb. 

CLUT unit 15 converts index colors in uncompressed 
graphics stored in I-graphics plane 15 to Y/Cr/Cb when 
operating in DVD-like mode (i.e. mode for playing digital 
streams like conventional DVD) . When operating in BD-J mode 

25 (i.e. mode for playing digital streams in sync with Java 
application} , CLUT unit 15 converts aRGB full color to 
Y/Cr/Cb, Note that a Java application may be bound or unbound 
to a title, as well as being bound or unbound to a disc. 



Audio decoder 16 decoded PES packets output from demux 
3 and outputs uncompressed audio data. 

The elements pertaining to AVClip playback are as 
described above . The following describes elements pertaining 
5 to operations in BD-J mode (network device 17 - demux 20) , 
Network device 17 realizes communication functions in 
the playback apparatus. In the case of an application 
specifying an URL in BD-J mode, network device 17 establishes 
a transmission control protocol (TCP) or file transfer 
10 protocol (FTP) connection etc. with the website indicated 
by the URL. Java applications are made to download from the 
website as the result of a connection being established. 

Local storage 18 is a hard disk for storing contents 
downloaded from a website via a connection established by 
15 network device 17, and contents supplied from communication 
and recording media other than BD-ROM, together with metadata . 
Metadata is information for binding and managing downloaded 
contents in local storage 18. By accessing local storage 18, 
applications in BD-J mode can perform a variety of processing 
20 using downloaded contents. Local storage 18 also holds merge 
management information files. 

Read buffer 19 is a FIFO memory that stores TS packets 
constituting SubClips on a first-in first-out basis in the 
case of SubClips being included in downloaded contents stored 
25 on BD-ROM 100 or in local storage 18. 

Demux 20 reads TS packets from read buffer 19 and 
converts the read TS packets to PES packets. PES packets 
having specific PIDs are then output to P-graphics decoder 
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6, font generator 9, and audio decoder 16. 

The above elements 17 to 20 enable contents downloaded 
by a Java application via a network to be played in a similar 
manner to contents recorded on BD-ROM, The following 
5 describes elements (instruction ROM 21 - switch 27) for 
realizing collective controls in the playback apparatus. 

Instruction ROM 21 stores software that defines 
controls relating to the playback apparatus. 

UE processing unit 22, in response to key operations 
10 of a remote controller or the front panel of the playback 
apparatus, outputs user events for performing these 
operations to CPU 24, 

PSR set 23 is a set of resisters internal to the playback 
apparatus composed of 64 player status registers (PSRs) and 
15 4096 general purpose registers (GPRs) , PSRs 4-8 are used to 
express the current playback point. 

PSR 4 indicates the title of the current playback point 
as a result of having been set to a value from 1-100. Setting 
PSR 4 to "0" indicates that the current playback point is 
20 the top menu, 

PSR 5 indicates the chapter number of the current 
playback point as a result of having been set to a value from 
1-999, Setting PSR 5 to "OxFFFF" indicates a null chapter 
number in the playback apparatus. 
25 PSR 6 indicates the number of the PL (current PL) to 

which the current playback point belongs as a result of having 
been set to a value from 0-999, 

PSR 7 indicates the number of the playitem (current 
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playitem) to which the current playback point belongs as a 
result of having been set to a value from 0-255. 

PSR 8 indicates the current playback point (current 
presentation time or "PTM") using 45-KHz time accuracy, as 
5 a result of having been set to a value from 0-OxFFFFFFFF, 
PSRs 4-8 enable the current playback point to be identified 
on a time axis for the entire BO-ROM shown in Fig.23A. 

CPU 24 runs software stored in instruction ROM 21 to 
execute controls relating to the entire playback apparatus . 
10 These controls change dynamically depending on user events 
output from UE processing unit 22 and the PSR values in PSR 
set 23. 

Scenario memory 25 is for storing current PL information 
and current clip information. Current PL information is the 
15 piece of PL information recorded on SD-ROM that is currently 
targeted for processing. Current clip information is the 
piece of clip information recorded on BD-R.OM that is 
currently targeted for processing. 

Local memory 26 is a cache memory for temporarily storing 
20 the recorded content of BD-ROM, given the slow reading speed 
from BD-ROM. The provision of local memory 26 allows 
applications in BD-J mode to run efficiently. 

Switch 27 selectively delivers data read from BD-ROM 
and local storage 18 to one of read buffer 2, read buffer 
25 19/ scenario memory 25 and local memory 26. 

The hardware configuration of a playback apparatus 
pertaining to the present embodiment is as described above. 
The following describes the software structure in a playback 



apparatus pertaining to the present embodiment. 

Fig. 19 depicts elements composed of hardware and 
software stored on instruction ROM 21 rearranged in a layer 
structure. As shown in Fig. 19, the layer structure of the 

5 playback apparatus is composed of a 1st layer (BD player), 
a 2nd layer (BD player model), and a 3rd layer (application 
runtime environment) , 

The hardware configuration of the playback apparatus 
shown in Fig. 18 belongs to the 1st layer. Of this hardware 

10 configuration, the U BD player" at the 1st layer in Fig. 19 
includes a ''decoder" composed of video decoder 4, P-graphics 
decoder 6, I-graphics decoder 10 and audio decoder 16, a 
"plane" composed of video plane 5, F~graphics plane 7 and 
X-graphics plane 12, BD-ROM 100 and relating filesystem, 

15 local storage 18 and relating filesystem, and network device 
17, 

The U BD player model" at the 2nd layer is composed of 
a lower layer for a presentation engine 31 and a virtual 
filesystem unit 38 and an upper layer for a playback control 
20 engine 32, with API functions being provided in relation to 
higher levels. 

PSR set 23 and scenario memory 25 shown in Fig. 18 exist 
inside playback control engine 32. 

The "application runtime environment" at the 3rd layer 
25 is composed of a layer that includes a module manager 33 
stacked on a layer that includes a DVD-like module 29a and 
a Java platform 29b. 

The following describes the elements in this software 



structure . 

DVD-like Module 29a, Java Platform 29b 

DVD-like module 29a decodes navigation commands and 
5 executes function calls in relation to playback control 
engine 32 based on the decoding result. 

Java platform 29b is a so-called Java platform having 
a hierarchical structure composed of a Java virtual machine 
30 and middleware for the Java virtual machine to operate 
10 (not depicted) . 

Java Virtual Machine 30 

Java virtual machine 30 loads xlet programs 
constituting applications into a work memory, decodes the 

15 xlet programs, and performs controls on lower layers in 
accordance with the decoding results. To perform these 
controls, Java virtual machine 30 issues a method to the 
middleware, has the middleware replace the method with a 
function call corresponding to a BD playback apparatus, and 

20 issues the function call to playback control engine 32 . 

Internal Structure of Java Virtual Machine 30 

The following describes the internal structure of Java 
virtual machine 30, Fig. 20 shows the internal structure of 
25 Java virtual machine 30. As shown in Fig. 20, Java virtual 
machine 30 is constituted from CPU 24, a user class loader 
52, a method area 53, a work memory 54, threads 55a, 55b, , . . 
55n, and Java stacks 56a, 56b, 56n. 
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User class loader 52 reads class files in Java archive 
files in the BDJA directory from local memory 26 or the like 
and stores the read class files in method area 53 . The reading 
of a class file by user class loader 52 is performed as a 

5 result of module manager 33 sending a read instruction 
specifying a file path to user class loader 52, If the file 
path indicates local memory 26, user class loader 52 reads 
a class file in a Java archive file constituting an 
application from local memory 26 to work memory 54. If the 

10 file path indicates a directory in a f ilesystem, user class 
loader 52 reads a class file in a Java archive file 
constituting an application from BD-ROM or local storage 18 
to work memory 54 . 

Method area 53 stores class files read from local memory 

15 26 by user class loader 52, 

Work memory 54 is a so-called heap area storing the 
instances of various class files. Work memory 54 stores 
instances corresponding to resident applications and class 
files read to method area 53, An instance is an xlet program 

20 constituting an application that is made executable by 
placing the xlet program in work memory 54. 

Threads 55a, 55b, . , . 55n are logical execution entities 
for executing methods stored in work memory 54 . They perform 
calculations using local variables and arguments stored in 

25 operand stacks as operands, and store calculation results 
in local variables or operand stacks. The arrows kyl, ky2 t 
and kyn in Fig, 20 symbolically indicate the supply of methods 
from work memory 54 to threads 55a, 55b, ... 55n, Whereas 
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the CPU is the sole physical execution entity/ there may be 
up to 64 logical execution entities or threads in Java virtual 
machine 30. Threads can be newly created and existing threads 
deleted within this numerical limit, and the number of 

5 operational threads can be varied while Java virtual machine 
30 is operating. Being able to appropriately increase the 
number of threads also makes it possible to run instances 
in parallel using a plurality of threads for each instance, 
and thereby speed up the execution of instances. 

10 Java stacks 56a, 56b, . . . 56n exist in a one-to-one ratio 

with threads 55a, 55b, . . . 5Sn, and each has a program counter 
("PC" in Fig. 20} and one or more frames. The program counters 
show which part of an instance is currently being executed- 
A frame is a stack-type area allocated to each call for a 

15 method, and is composed of an operand stack for storing 
arguments occurring at the time of the call and a local 
variable stack ("local variable" in Fig. 20) for use by the 
called method. Since frames are stacked on Java stacks 56a, 
56b, . „ . 56n whenever a call is made, the frames of a method 

20 that calls itself recursively also get stacked one on top 
of the other. 

The internal structure of the Java virtual machine is 
as described above. A Java virtual machine having the above 
structure serves as an event-driven execution entity. This 
25 completes description of the Java virtual machine* 

Presentation Engine 31 

Presentation engine 31 executes AV playback functions. 
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The AV playback functions of a playback apparatus are a 
traditional group of functions inherited from DVD players 
and CD players, including PLAY, STOP, PAUSE ON, PAUSE OFF, 
STILL OFF, FAST FORWARD PLAY (x2, x4 etc.), FAST BACKWARD 

5 PLAY (x2, x4 etc.), AUDIO CHANGE, SUBTITLE CHANGE, and ANGLE 
CHANGE. To realize these AV playback functions, presentation 
engine 31 controls video decoder 4, P-graphics decoder 6, 
I-graphics decoder 10 and audio decoder 16 to decode the 
portion of an AVClip read to read buffer 2 that corresponds 

10 to a desired time- By having the place indicated by PSR 8 
(current PTM) decoded as the desired time, arbitrary points 
in an AVClip can be rendered playable. 

Playback Control Engine 32 

15 Playback control engine 32 executes various functions 

including {i} playback controls on playlists and (ii) 
acquiring/setting the status of PSR set 23. The playback 
control function involves having presentation engine 31 
execute PLAY and STOP out of the above AV playback functions, 

20 in accordance with current PL information and clip 
information. Functions {i} and (ii) are executed according 
to function calls from DVD-like module 29a and Java platform 
29b. 

Synchronization of the processing by playback control 
25 engine 32 with the processing by the Java virtual machine 
is described next. Playback control engine 32 executes 
processing based on PL information when a function is called. 
This processing is performed for the duration of the AVClip 



for playback, whether the playback time is 15 minutes or 30 
minutes. A problem here is the time lag between when Java 
virtual machine 30 returns a success response and when 
playback control engine 32 actually ends the processing. Java 

5 virtual machine 30, being an event-driven execution entity, 
returns a response indicating whether playback was 
successful or not immediately after the call, whereas 
playback control engine 32 ends playback of the AVClip and 
playiterns after the 15 or 30-minute playback duration has 

10 elapsed. Thus, the time at which a success response is 
returned to an application cannot be used as a basis for 
gauging the end of processing 15 or 30 minutes later. Gauging 
the end of processing becomes all the more difficult when 
fast-forwarding or rewinding is performed during PL playback 

15 since the playback time of 15 or 30 minutes is then subject 
to change . In view of this, playback control engine 32 outputs 
events indicating the end of playitem and AVClip playback 
to an application when playback of a respective playitem or 
AVClip ends. This output enables the application to know the 

20 points at which playback control engine 32 concluded playitem 
and AVClip playback. 

Module Manager 33 

Module manager 33 reads INDEX * BDMV and chooses one of 
25 the pieces of title information in INDEX , BDHV as current 
title information. Module manager 33 reads a BD-J object 
indicated by the current title information and controls 
playback control engine 32 to perform playback controls based 



on PL information described in the BD-J object. Module 
manager 33 also controls Java virtual machine 30 to read and 
execute Java archive files described in the BD-J object, 
If playback of a digital stream based on PL information 

5 and execution of the applications ends or if the user calls 
a menu, module manager 33 reads title information defining 
another title and chooses this piece of title information 
as the current title information. The choosing of another 
piece of title information as the current title information 

10 according to digital stream playback or a user menu call is 
called a "title change". 

The status transition shown in Fig, 21 can be realized 
by repeatedly performing title changes. The oval windows in 
Fig, 21 represent titles. 

15 The titles include a "FirstPlayTitle" for playback when 

a BO-ROM is first loaded, a "TopjmenuTitle" constituting a 
top menu, and other general titles . The arrows jhl, jh2 f jh3 r 
jh4 f jh5 f jh6, jhl and jh8 in Fig, 21 symbolically indicate 
branching between titles. 

20 The status transition shown in Fig. 21 involves playing 

FirstPlayTitle when the BO-ROM is loaded, and then branching 
to Top_menuTitle and waiting for a selection from the top 
menu , 

When the user selects from the menu, the respective title 
25 is played in accordance with the selection, before again 
returning to TopjmenuTit le . The endless repetition of this 
processing until the disc is ejected is a status transition 
peculiar to disc contents . This status transition is realized 



under the control of module manager 33 described above. 

This completes description of Java virtual machine 30/ 
presentation engine 31, playback control engine 32, and 
module manager 33. The controls on playback control engine 
5 32 by Java virtual machine 30 are performed via a virtual 
package. To realize controls on playback control engine 32 
via a virtual package, the playback apparatus includes a 
network management module 37 and a virtual filesystem unit 
38. These elements are describes next. 

10 

Network Management Module 37 

Network management module 37 downloads data required 
for creating virtual packages from websites administrated 
by the providers of movie works, in accordance with method 

15 calls from applications. This data includes files (PL 
information, clip information, AVClips, Java archive files 
etc.) that either replace or add to merge management 
information files, signature information files, and files 
on BDHROM* When download requests are made by applications 

20 in work memory 54, network management module 3 7 downloads 
data required for creating virtual packages via a network 
and writes the downloaded data to local storage 18. 

Virtual Filesystem Unit 38 
25 Virtual filesystem unit 38 is an element belonging to 

the 2nd layer in Fig. 19 that creates virtual packages in 
accordance with method calls from applications . The creation 
of a virtual package includes processing to manage the status 
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of AVClips constituting the virtual package and processing 
to generate virtual package information. 

Virtual Package Information 

5 Virtual package information expands the volume 

management information on BD-ROM. The volume management 
information referred to here defines the directory structure 
existing on recording media, and is composed of directory 
management information relating to directories and file 

10 management information relating to files. 

Virtual package information expands the directory 
structure on BD-ROM by adding new file management information 
to the volume management information showing the directory 
structure. The file management information added to the 

15 volume management information relates to PL information, 
clip information, AVClips and Java archive files existing 
in local storage 18. Creating virtual package information 
to which this file management information has been added and 
providing this virtual package information to playback 

20 control engine 32 enables the playback control engine to 
recognize PL information, clip information, AVClips and Java 
archive files stored in local storage 18 as existing on BD-ROM. 
Fig. 22 shows an exemplary creation of virtual package 
information by virtual filesystem unit 38, At the top left 

25 of Fig. 22 is the directory structure on BD-ROM, this being 
the same as Fig. 2. At the bottom left is the directory 
structure in local storage 18, this being the same as Fig. 14 . 
File management information relating to PL information, clip 
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information, AVClips, and Java archive files in local storage 
18 are added to the volume management information on BD-ROM- 
Specifically: 

i) file management information relating to playlist 
5 information#2 (00002. mpls) in local storage 18 is added to 

the directory management information in the PLAYLIST 
directory; 

ii) file management information relating to clip 
information#2, #3 and #4 (00002. clip, 00003. clip, 

10 00004. clip) in local storage 18 is added to the directory 
management information in the CLIPINF directory; 

iii) file management information relating to AVClips#2, 
#3 and #4 (00002. m2ts, 00003, m2ts, 00004,m2ts) in local 
storage 18 is added to the directory management information 

15 in the STREAM directory; and 

iv) file management information relating to the Java 
archive file "00002 . jar" in local storage 18 is added to the 
directory management information for the BDJA directory. 

Virtual package information is thus obtained. In other 
.20 words, virtual package information is volume management 

information that has been added to in the above manner. 

This virtual package information is then provided to 

playback control engine 32, which is thereby able to treat 

PL information, clip information, AV clips, and Java archive 
.25 files in local storage 13 on an equal basis with PL information, 

clip information, AVClips, and Java archive files on BD-ROM . 

The generation of virtual package information is as described 

above - 
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The following describes the timing at which virtual 
package information is updated. 

Assume that the BD-ROM is ejected after branching 
performed in the numerical order of the reference signs 

5 indicated by the arrows jhl f jh2 f jh3, jh4 etc, in Fig. 21. 
This enables the contiguous timeslot from the loading to the 
ejecting of the BD-ROM to be viewed as a single time axis* 
This time axis is taken as the time axis for the entire disc. 
Fig . 23A shows the time axis for the entire disc, while Fig . 23B 

10 shows the structure of this time axis. As shown in Fig.23B, 
the time axis for the entire disc is composed of intervals 
during which FirstPlayTitle is played, intervals during 
which Top__menuTitle is played, and intervals during which 
general titles (Title#l etc J are played. As for the manner 

15 in which the playback intervals of these titles are defined, 
since each title is constituted from only one BD-J object; 
the period during which any given BD-J object is valid can 
be regarded as the playback interval of a title. The space 
between these playback intervals, or rather the interval for 

20 changing from one title to another (i.e. x 'titie change")/ 
is when the virtual package information is updated. 

A procedure for downloading new merge management and 
signature information files and content files by a Java 
application is described next using Fig. 24, 

25 The Java application firstly sends the current merge 

management information file to the server (step S12) , thereby 
requesting a download, and judges whether data has been 
received from the server (step S12) . When data is downloaded, 



the Java application creates a new directory in a 
corresponding disc directory and writes the downloaded merge 
management information file and signature information file 
to the new directory (step S13) . Note that if the filenames 
5 of the downloaded merge management and signature information 
files do not coincide with the existing merge management and 
signature information files in the disc directory, the 
downloaded files may be placed directly under the existing 
directory (disc#l directory) without creating a new 

10 directory. Downloaded AVClips, clip information, PL 
information, and Java archive files are written to the 
corresponding directory {step S14), The Java application 
then calls an update request method using the file paths of 
the new merge management and signature information files as 

15 arguments (Step S15) . The Java application judges whether 
the return value is false {step S16) , and terminates the 
processing if false. If the return value is not false, the 
Java application executes processing using the updated 
virtual package information (step S17) . 

20 Note that while the above processing is described in 

terms of the Java application sending the current merge 
management information file to the server when requesting 
a download, the Java application may send only the ID of the 
merge management information file. 

25 An update "preparing" procedure performed by virtual 

filesystem unit 38 upon receipt of an update request is 
described next using Fig. 25, 

Virtual filesystem unit 38 firstly reads the new merge 
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management and signature information files using the file 
paths that serve as arguments when calling a method (step 
S21), and verifies the signature in order to check whether 
the new merge management information file has been tampered 
5 with (step S22) „ Exceptional termination is carried out if 
the signature cannot be verified, if the signature is 
verified, virtual filesystem unit 38 checks the authority 
of the calling application (step S23) , Exceptional 
termination is carried out if the calling application is 

10 unauthorized. If the calling application is authorized, 
virtual filesystem unit 38 judges whether files specified 
by the new merge management information file actually 
existing in local storage (step S24) . Exceptional 
termination is carried out if these files do not exist, if 

15 these files do exist, virtual filesystem unit 38 changes the 
new merge management and signature information files and all 
the files in local storage referenced from the new merge 
management information file to read-only (step S25) . 

Fig. 26 is a flowchart of virtual package "updating" 

20 processing by virtual filesystem unit 38 . Virtual filesystem 
unit 38 firstly identifies the disc directory corresponding 
to the loaded BD-ROM and replaces the merge management and 
signature information files in the disc directory with the 
new merge management and signature information files 

25 specified by the file paths that serve as arguments when the 
Java application calls the update request method (step S31) . 
Virtual filesystem unit 38 then adds the file management 
information of PL information specified by the merge 



management information file in local storage 18 to the 
directory management information in the PLAYLIST directory 
(Step S32), and executes the loop of steps S33 to S37, This 
loop involves repeating steps S34 to S36 for each piece of 

5 clip information existing in local storage 18. Here, a piece 
of clip information targeted for loop processing is given 
as clip information x. Virtual filesystem unit 38 identifies 
an AVClip corresponding to clip information x (step S34), 
adds the file management information of clip information x 

10 specified by the merge management information file in local 
storage 18 to the directory management information in the 
CLIPINF directory (step S35) r and adds the file management 
information of AVClip x specified by the merge management 
information file in local storage 18 to the directory 

15 management information in the STREAM directory (step 336) . 
By repeating the above processing for all clip information 
and AVCiips in local storage 18, file management information 
relating to the clip information and AVCiips is added to the 
volume management information. The volume management 

20 information thus obtained is virtual package information. 
Virtual filesystem unit 38 provides this virtual package 
information to the application that made the virtual package 
call (step 338} , and ends the processing. 

Fig. 27 is a flowchart of the processing by module manager 

25 33. 

Module manager 33 firstly chooses FirstPlayTi tie as the 
current title (step 341), specifies the BD-J object 
corresponding to the current title as the current BD-J object 



(step S42} , and has playback control engine 32 execute PL 
playback based on PL information described in the current 
BD-J object (step S43) . Module manager 33 then has Java 
platform 29b run Java applications whose lifecycle is the 

5 current title in the application management table of the 
current BD-J object (step S44), and has Java platform 29b 
terminate Java applications whose lifecycle is not the 
current title (step S45) - Module manager 33 then judges 
whether PL playback based on the current PL information has 

10 been completed (step S46) and if completed, module manager 
33 identifies the next title (step S47), and chooses this 
title as the current title (step S48) . If current PL playback 
is not yet completed, module manager 33 judges whether a title 
call has occurred (step S49} and moves to step S47 if this 

!5 is the case. If a title call has not occurred, module manager 
33 judges whether a title jump has occurred (step S50) , and 
moves to step S47 if this is the case. If a title jump has 
not occurred, module manager 33 judges whether a main 
application of the current title has ended (step 351} and 

20 moves to step S47 if this is the case. If the main application 
has not yet ended, module manager 33 returns to step S46. 

Fig. 28 is a flowchart of playback processing by playback 
control engine 32, Playback control engine 32 executes the 
loop of steps S62 to S68 after setting the first piece of 

25 Playltem information in the current PL information as 
Playltem i (step S61) ♦ The control variable in this loop is 
variable i. Playback control engine 32 increments control 
variable i by "1" at step S68 after executing steps S62 to 

42 



S66 until variable i exceeds the number of playitems (step 
S67) . 

Steps S62 to S66 are described next, Playback control 
engine 32 sets the AVClip described in 

5 Clip_information_f ile_name in Playltem i as AVClip j (step 
362} r and instructs the drive device and decoder to play 
AVClip j from the Playltem. InJ:ime to Playltem. Gut^time 
(step S63) . Playback control engine 32 judges whether there 
exists a SubPlayltem k specifying Playltem i in 

10 Sync_PiayItem_Id (step S64}, and moves directly to step S67 
if this SubPlayltem does not exist. If SubPlayltem k does 
exist, playback control engine 32 sets the AVClip described 
by Clip_information_file_name of SubPlayltem * as AVClip h 
(step S65), instructs the drive device and decoder to 

15 playback AVClip h from Sync_Start_PTS_of_PlayI tern to 
Out_time (step S66), and moves to step S67, 

A stream sequence defined by the PL information is played 
as a result of this processing being repeated for all of the 
Playltem information constituting the PL information. 

20 Fig. 29 shows how virtual package information is updated 

during a title change. 

The 1st tier in Fig, 29 shows title playback intervals 
on the time axis, the 2nd tier shows a Java application whose 
lifecycle is TitleH, the 3rd tier shows a digital stream, 

25 and the 4th tier shows the status of virtual f ilesystem unit 
38. 

Virtual filesystem unit 38 is placed in a "preparing" 
state upon receipt of an update request from the Java 

43 



application, and performs the processing shown in Fig. 25. 

After performing this processing, virtual filesystem 
unit 38 waits in a "prepared" state for a title change. When 
a title change occurs, virtual filesystem unit 38 is placed 
5 in an "updating" state, and executes the processing shown 
in Fig, 26 to update the virtual package, before reverting 
back to a "stable" state. If Title#l is again selected from 
Top_menuTitle after virtual filesystem unit 38 has reverted 
back to a "stable" state, Title#l is played using the updated 
10 virtual package. 

Here, a title change occurs when module manager 33 
chooses a different title as the current title due, for 
instance, to playback of a stream sequence ending or a menu 
being called by a user. 
15 The above processing is schematically described using 

Figs. 30 to 33. 

Fig. 30 shows a Java application sending the current 
merge management information file to the server. The files 
shown under ROOT are located in local storage, while the files 
20 under BDMV are located in a virtual package. 

Fig. 31 shows the Java application downloading content 
files, a new merge management information file, and a new 
signature information file. "00012. dpi" and "00012, m2ts" 
are downloaded content files, while the merge management and 
25 signature information files stored in the newMF directory 
have been newly downloaded. 

Fig. 32 shows a Java application requesting virtual 
filesystem unit 38 to update the existing merge management 
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and signature information files to the newly downloaded files . 
This update request is made by using the file paths to specify 
the new merge management and signature information files. 
Fig, 33 shows the replacement of merge management and 

5 signature information files, and the mapping of content files . 
The replacement of the old merge management and signature 
information files during updating is shown on the left side 
of Fig* 33 , The mapping of content files after the title change 
is shown on the right side of Fig. 33. 

10 Note that the read-only attribute of files referenced 

from the old merge management information but not from the 
new merge management information is removed, making these 
files writable by a Java application. 

The merge management information file includes 

15 information indicating the location of contents added to 
local storage. Information indicating the location of 
additional contents includes content IDs , the directory 
paths of directories in which the contents are stored, or 
the file paths of individual content files. Filename-mapping 

20 information may be described in the merge management 
information file when mapping these files to a virtual 
package, so as to enable these files to be accessed under 
different filenames in the virtual package. Here, 
filename-mapping information maps filenames (including file 

25 path) in a virtual package with filenames (including file 
path) in local storage. 

In this case, virtual packages are created by virtual 
f ilesystem unit 38 as virtual package media constituted from 



files whose filenames in the virtual package described in 
the filename-mapping information have been added to the file 
structure on BD-ROM . Files in a virtual package accessed by 
a Java application are specified as files in the virtual 
5 package rather than as files on BD^ROM or in local storage. 
When a Java application requests access to a file in a virtual 
package, virtual filesystem unit 38 switches the access 
destination to either local storage or BD-ROM based on the 
filename-mapping information. If the desired file is 

10 described in the filename-mapping information, the access 
destination is changed to a corresponding file in local 
storage. If the desired file is not described in the 
filename-mapping information, the access destination is 
changed to a corresponding file on BD-ROM. 

15 In other words, the creator of a Java application need 

not be aware of the medium (BD-ROM or local storage) on which 
individual files are stored, since virtual filesystem unit 
38 switches the access destination of a file specified in 
a virtual package by a Java application to the medium actually 

20 storing the file, thereby lightening the burden of program 
creation. 

According to the present embodiment, a virtual package 
is updated during a title change, meaning that the 
replacement of a playback object will not cause abnormal 
25 operation of the playback apparatus. 



Embodiment 2 

The present embodiment relates to an improvement when 
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title calls are performed, A title call results in the called 
title being played after firstly suspending the current title, 
and the original title then being resumed after playback of 
the called title has ended. Since title calls are premised 
5 on playback being resumed, playback control engine 32 saves 
system parameters for playback controls stored in PSRs to 
backup PSRs when a title is called, and restores the saved 
parameters to the PSRs after playback of the called title 
has ended, 

10 The following is a list of system parameters stored in 

PSRs. PSR 0 to PSR 12 store system parameters showing playback 
status, PSR 13 to PSR 19 store system parameters set by the 
player as preferences, and PSR 20 to PSR 32 are backup PSRs. 



15 


PSR 


0 : 


I-Graphics Stream Number 




PSR 


1 : 


Audio Stream Number 




PSR 


2 : 


P-Graphics Stream/TextST Stream Number 




PSR 


3 : 


Angle Number 




PSR 


4 : 


Current Title Number 


20 


PSR 


5 : 


Current Chapter Number 




PSR 


6 : 


Current Playlist ID 




PSR 


7 • 


Current Playitem ID 




PSR 


8 


Playback Time Information 




PSR 


9 


Navigation Timer 


25 


PSR 


10 


Selection Key Information 




PSR 


11 


Current Page ID in I-Graphics Stream 




PSR 


12 


: User Style ID in P-Graphics Stream & TextST 



Stream 
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PSR 13 : Parental Level 
PSR 14 : Subtitle Support Information 
PSR 15 : Player Setting Value (Audio) 
PSR 16 : Language Code for Audio Stream 
5 PSR 17 : Language Code for P-Graphics Stream & TextST 

Stream 

PSR 18 : Language Code for Menu 
PSR 19 : Version Information of Player 
PSR 20 : Backup for PSR 0 
PSR 21 : Backup for PSR I 
PSR 22 : Backup for PSR 2 
PSR 23 : Backup for PSR 3 
PSR 24 : Backup for PSR 4 
PSR 25 : Backup for PSR 5 
PSR 26 : Backup for PSR 6 
PSR. 27 : Backup for PSR 7 
PSR 28 : Backup for PSR 8 
PSR 29 : Backup for PSR 9 
PSR 30 : Backup for PSR 10 
PSR 31 : Backup for PSR 11 
PSR 32 : Backup for PSR 12 

Updating virtual package information during a title 
call result in differences in the virtual package information 
25 before and after the call. 

Since the virtual package information will have changed 
when the original title is restored, errors may arise if 
playback control engine 32 attempts to play the original 
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title using the backup values. This problem is avoided by 
clearing the backup PSRs when a Java application has 
requested updating. However, given that the change may have 
no effect depending on the content of the merge management 
5 information file, the decision as to whether to clear the 
system parameter values can be left up to the Java 
application . 

Fig. 34 A is a flowchart of processing by playback control 
engine 32 when suspending playback of the current title after 

10 a title call. Fig. 34B is a flowchart of processing by playback 
control engine 32 when resuming playback of the original 
title after playback of the called title has ended. 

When current title playback is suspended, playback 
control engine 32 saves PSRs 0-12 to PSRs 20-32 (step S71). 

15 When original title playback is resumed after playback 

of the called title has ended, playback control engine 32 
firstly judges whether the virtual package information has 
been updated (step S81) . PSRs 2Q™32 are restored to PSRs 0-12 
(step S83) if not updated, while PSRs 20-32 are initialized 

20 (step S82) before performing step S83 if the virtual package 
information has been updated. 

According to the present embodiment, backup PSRs are 
initialized when the virtual package information has been 
updated during a title call, thereby removing the danger of 

25 playback errors occurring when original title playback is 
resumed. The stable operation of playback control engine 32 
is thus enabled. 

Note that system parameter values in the PSRs may be 
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mandatorily cleared when virtual package information is 
updated, rather than leaving this decision up the Java 
application , 

5 Embodiment 3 

The present embodiment relates to a method for managing 
the version of merge management information and specifying 
additional contents for merging from a resident application 
in the playback apparatus. Fig. 35 shows an exemplary content 

10 of a merge management information file pertaining to the 
present embodiment- In embodiment 1, the merge management 
information file (or rather the merge management information 
stored therein) is updated by overwriting the old merge 
management information, resulting in the old information 

15 being erased- In the present embodiment , new merge management 
information is continually added to the file without 
overwriting the old information even for the same disc ID. 
Thus, if virtual filesystem unit 38 cancels creation of a 
virtual package and reverts back to the original BD-ROM, 

20 information that reflects this state is retained in the merge 
management information file. In this case, the corresponding 
cell in the merge-target directory of the merge management 
information file is either left blank or inscribed with a 
character string indicating the original BD-ROM. 

25 Retaining (a history of) previous merge management 

information in the merge management information file is 
enabled by not overwriting old merge management information 
when updating is performed, and then if the user wants an 
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old version of a virtual package, the old version can be 
created with reference to previous merge management 
information. Furthermore, virtual packages previously 
created by the user can be created with reference to the merge 

5 management information file (or rather the old merge 
management information stored therein} from not only a Java 
application but also from a resident application in the 
playback apparatus. 

Another example of the use of previous merge management 

10 information by a resident application involves displaying 
an additional contents list so that the user can delete 
unwanted additional contents from the resident application* 
Since the merge management information file can be used to 
distinguish directories storing additional contents, 

15 additional contents can also be retrieved and deleted from 
an application (i.e. a resident application) other than the 
Java application that stored the additional contents. 

Fig. 36 shows a Java application pertaining to the 
present embodiment requesting a virtual package update. A 

20 difference with embodiment 1 lies in the fact that merge 
management information is continually added without 
overwriting the old information even when merge management 
information for the targeted disc ID already exists. The Java 
application allows the latest piece of merge management 

25 information in the merge management information file to be 
identified by appending date information when a virtual 
package update is requested. Date information is not limited 
to being a date, and may simply be a consecutive number. 



Fig. 37 shows an exemplary additional contents list 
displayed to the user by a resident application using a merge 
management information file. Here, the displayed additional 
contents list is based on the merge management information 

5 file shown in Fig. 35, It is desirable to display information 
that enables the user to grasp what the additional contents 
relate to. The additional contents in Fig. 37 are displayed 
as content names. While only date information is added to 
the merge management information in Fig, 36, synopses of the 

to additional contents may also be added, since resident 
applications are able to perform such display, in this case, 
synopses of the additional contents are provided for input 
together with content IDs when the Java application requests 
a virtual package update. These synopses may specify file 

15 paths to files containing respective synopses, rather than 
simply involving the direct input of character strings. The 
merge management information thus stores content synopses 
in addition to update dates, and a resident application is 
able to display these synopses in the additional contents 

20 list together with the date information. 

Rather than having the Java application specify content 
synopses, meta-inf ormation showing what specific contents 
are about may be appended to the contents themselves, and 
a resident application may read this information and display 

25 synopses based on the read information. 

The "ADDED ON" column in Fig, 37 shows the dates on which 
respective additional contents were first merged with the 
BD-ROM, This information may also be read from the merge 



management information . 

Note that the dates on which additional contents were 
first merged may be held separately to the merge management 
information. These dates may also be determined from the 

5 dates on which directories for storing the additional 
contents were created. When one of the select buttons 
displayed in the additional contents list is depressed, the 
resident application writes the directory path/disc ID of 
the selected content and the selection date to the merge 

10 management information file as corresponding merge 
management information . In other words, the additional 
content most recently selected becomes the latest merge 
management information- If the original BD-ROM is selected, 
either a value indicating the original BD-ROM or a blank cell 

15 is inserted in the merge-target directory of the merge 
management information file. When one of the delete buttons 
displayed in the additional contents list is depressed, the 
resident application reads the directory of the additional 
content for deletion with reference to the merge management 

20 information file, and deletes this directory, Merge 
management information corresponding to the content ID of 
this content is also deleted from the merge management 
information file. 

Fig. 38 is a flowchart of the processing flow pertaining 

25 to the present embodiment from the loading of a BD-ROM until 
playback. Virtual filesystem unit 38 firstly checks the disc 
ID of the loaded BD-ROM (stepS91), reads the merge management 
information file (step S92) , and judges whether there exists 



merge management information corresponding to the disc ID 
of the loaded BD-ROM (step S93). If judged in the negative 
(step S93=NO) , playback is performed using only the original 
BD-ROM (step S94). If judged in the affirmative (step 

5 S93=YES) , a virtual package is created using the latest merge 
management information (step S95) . During creation of a 
virtual package, virtual filesystem unit 38 judges whether 
an error has been detected (step S96) , If judged in the 
affirmative {step S96=YE5), virtual filesystem unit 38 

10 judges whether there exists prior merge management 
information that corresponds to the disc ID of the BD-ROM 
(step S97) . If judged in the affirmative (step S97=YES) , a 
virtual package is created using the version of merge 
management information preceding the latest merge management 

!5 information (step S98), If judged in the negative (step 
S97=NO) , playback is performed using only the original BD-ROM 
(step S94) . If an error is not detected at step S96, playback 
is performed using the created virtual package {step S99) . 
Exemplary errors include mistakes in the latest merge 

20 management information and the non-existence of streams 
referenced from a playlist etc. 

According to the present embodiment, virtual packages 
can be created from a resident application in the playback 
apparatus using old versions of merge management information 

.25 with reference to the content history of the merge management 
information file, by holding previous merge management 
information in the merge management information file. If an 
error occurs during the creation of a virtual package, the 
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problem can be avoided by creating an old version of a virtual 
package as an alternative course of action- 

Embodi ment 4 

5 The present embodiment relates to a method for 

specifying the valid period of a virtual package when a 
virtual package update is requested by a Java application, 
and using the virtual package to perform playback only within 
the valid period, 

10 Fig* 39 shows a valid interval being specified when a 

virtual package update is requested. The Java application 
specifies both the content ID of an additional content for 
merging and a valid period for use of the virtual package. 
For example, if the user wants to play contents as a virtual 

15 package until the disc is ejected and then play contents using 
only the original BD-ROM after reloading the disc, a value 
indicating that the virtual package is valid until the disc 
is ejected is specified in an argument when a virtual package 
update is requested from the Java application. 

20 Fig, 40 is a flowchart of the processing flow pertaining 

to the present embodiment from the loading of a BD-ROM (or 
rebooting of the playback apparatus) until playback. Virtual 
filesystem unit 38 firstly checks the disc ID of the loaded 
BD-ROM (step S101), reads the merge management information 

25 file {step S102), and judges whether there exists merge 
management information corresponding to the disc ID of the 
loaded BD-ROM (step S103) . If judged in the negative (step 
S103=NO), playback is performed using only the original 
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BD-ROM (step S104). If judged in the affirmative (step 
3I03=YE3), virtual filesystem unit 38 judges whether the 
corresponding merge management information is within the 
valid period (step S105) . If no longer valid, the 

5 corresponding merge management information is deleted (step 
S106), and playback is performed using only the original 
BD-ROM (step S104) . If still valid, the corresponding merge 
management information is used to create a virtual package 
(step S107), and playback is performed using the virtual 

10 package (step S108) . 

Note that a pattern in which Java mode only virtual 
packages are created is also conceivable as an application 
of the present embodiment, if Java mode only is specified 
when virtual package creation is requested from a Java 

15 application, virtual filesystem unit 38 creates a virtual 
package when there is a transition from DVD-like mode to Java 
mode, and then shifts to Java mode. Conversely, when there 
is a transition from Java mode to DVD-like mode, virtual 
filesystem unit 38 shifts to DVD-like mode after canceling 

20 the virtual package and reverting back to the original 
BD-ROM. 

According to the present embodiment, it is possible to 
specify a valid period for playback using a virtual package, 
thereby enabling playback using once-only virtual packages 
25 (i.e. virtual packages that are disabled once the BD-ROM is 
ejected), and creation of virtual packages with use period 
limitations . 

Note that while in the present embodiment a valid period 
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is specified when a virtual package update is requested, a 
valid period may also be specified when virtual package 
creation is requested after loading a BD-ROM . 



5 Embodiment 5 

The following is a detailed description regarding the 
authority of the calling application at step S23 in Fig. 25 
of embodiment 1. Specifically, the present embodiment 
relates to a method of denying virtual package update 

10 requests from unauthorized Java applications. 

Fig, 41 shows permission request files being used to 
screen virtual package update requests* As described above, 
a virtual package update is performed on the basis of update 
requests from Java applications. However, when updating is 

15 performed on the basis of a request from an unauthorized Java 
application, there is a danger of the content of the disc 
being illegally updated in terms of viewing restrictions 
being changed or the playback of video clips that can only 
be viewed under certain conditions being enabled. In view 

.20 of this, a virtual package update according to the present 
embodiment can only be requested from Java applications that 
hold updating permission, which is information showing that 
permission to request updating has been granted. Whether or 
not updating permission is held is judged by checking the 

25 content of a permission request file corresponding to a Java 
application that issues a request. Specifically, a class 
loader restricts the functions of Java applications in 
accordance with the content of respective permission request 



files. For example, an update request is processed if an 
update attribute value in the permission request file is 
"true" but denied if "false". 

Fig. 42 shows access restrictions imposed on a directory 

5 in local storage targeted for merging. If the content of a 
directory targeted for merging is altered by an unauthorized 
Java application, there is a danger of the content of the 
virtual package being illegally changed despite update 
requests being screened. In view of this, permission to 

10 access local storage is also restricted on the basis of the 
content of respective permission request files. For example, 
if both the read and write attribute values in a permission 
request file are "true", downloaded contents can be written 
and stored files can be read and edited. File access 

15 restrictions will be imposed, however, on Java applications 
with a permission request file in which either or both of 
the read and write attribute values are "false", or Java 
applications without a permission request file. 

According to the present embodiment, unauthorized Java 

20 applications can be prevented from having virtual packages 
updated and changing the content of directories in local 
storage . 

The following is a specific example of the use of 
permission request files to restrict virtual package 
25 updating. Consider an example in which directories are 
allocated in local storage to specific providers of movie 
works. Specifically, assume that contents provided by A 
Studios, B Studios and C Inc. are stored both in local storage 



and on BD-ROM . Here, C Inc. is the provider of digital 
magazines. It would be problematic when merging contents in 
local storage with BD-ROM if, for instance, contents provided 
by B Studios were merged with contents provided by A Studios. 
5 In view of this, updating permission is only granted to C 
Inc. (i.e. update attribute value in permission request file 
set to "true") , thereby enabling various services to be made 
available. A Studios and B Studios are only able to merge 
their own contents. 

10 

Embodiment 6 

The present embodiment relates to a method for updating 
a virtual package during a title change in the case of Java 
applications that operate across a plurality of titles. 

15 Fig, 43 shows both Java applications whose lifecycle is 

limited to a single title and Java applications whose 
lifecycle spans a plurality of titles. The lifecycles of Java 
applications are shown in application management information, 
and module manager 33 manages the start and end of Java 

20 applications in accordance with this application management 
information. Java applications includes those that can only 
exist within the title in which they were started 
(hereinafter "title-bound applications") and those that can 
exist over a plurality of titles (hereinafter "title-unbound 

25 applications"} . The application management information 
contains title numbers, application IDs and information 
showing whether particular Java application are bound or 
unbound . 



In the application management information shown in 
Fig. 43, for example, Java application*! is bound and Java 
application^ is unbound in title#l« Module manager 33 
terminates bound Java application^ together with the end 
5 of title#l- On the other hand, unbound Java application#2 
is allowed to live past the end of title#l, with the decision 
of whether or not to terminate this application being made 
according to the application management information of the 
next title. Since the application management information in 
10 the Fig. 43 example shows that Java application#2 can exist 
in both titleftl and title#2, this application is allowed to 
live through the transition from titlettl to title#2. Because 
Java application#2 is title-bound in title#2, however, 
module manager 33 terminates the application together with 
15 the end of this title. 

Fig. 44 shows processing performed on a title-unbound 
application when a virtual package is updated during a title 
change. As shown in Fig ,43, title-unbound applications that 
can exist in both the title before and the title after a title 
20 change continue operating through the title change. However, 
if a virtual package update is requested, all applications 
including title-unbound applications are terminated during 
a title change. After the virtual package has been updated, 
title-unbound applications are then restarted together with 
25 title-bound applications belonging to the next title. 

Fig. 45 is a flowchart of title change processing that 
takes title-unbound applications into consideration. When 
title playback is started (step Sill), virtual filesystem 
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unit 38 firstly judges whether a virtual package update has 
been requested from a Java application during current title 
playback (step S112) - If judged in the affirmative (step 
S112^YES), virtual filesystem unit 38 performs update 

5 preparation (step S113). When a title change occurs (step 
S114), virtual filesystem unit 38 judges whether the update 
request has been processed (step S115) - If judged in the 
affirmative (step S115-YES), all applications including 
title-unbound applications are terminated (step S116), and 

10 the virtual package is updated (step S117). The next title 
is then played after the title change (step S118) . If a virtual 
package update has not been requested at step S112 or if an 
update request has not been processed at S115, module manager 
33 terminates only title-bound application when a title 

15 change occurs {step S119) . 

Since the present embodiment ensures that all 
applications are terminated during the updating of virtual 
packages, it is possible to prevent any loss of consistency 
after the completion of virtual package updating in terms 

20 of references to old pre-update files remaining or new files 
existing along side old files still in cache. 

Note that if a Java application capable of existing over 
a plurality of discs ( n disc-unbound application") is 
operating when a title change occurs after virtual package 

25 updating has been requested, the disc-unbound application 
can continue operating without being forcibly terminated by 
treating the virtual package update in the same manner as 
a disc changing operation. 
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Note also that module manager 33 may manage the start 
and end of a title-unbound application after a title change 
has occurred^ in accordance with application management 
information updated after the completion of virtual package 
5 updating, without terminating the title-unbound application 
during the update. In this case, the title-unbound 
application is made to reference the pre-update virtual 
package until the updating is completed. 

10 Embodiment 7 

The present embodiment relates to virtual package 
updating following a change in an INDEX. BDMV file. Upon 
receiving a virtual package update request from a Java 
application, virtual filesystem unit 38 confirms that an 

15 INDEX . BDMV file exists in the directory targeted for merging. 
If an INDEX. BDMV file exists, virtual filesystem unit 38 
reads the INDEX - BDMV file in preparation for the updating. 
The existing INDEX . BDMV file is then invalidated and a new 
INDEX . BDMV file is validated. This new INDEX. BDMV file is 

20 then used prior to a title change if, for example, a resident 
application of the BD player performs a title search or a 
Java application acquires title information. In other words, 
informing Java applications and users beforehand of the 
post-updating title structure makes it possible to prevent 

25 title changes to titles that will cease to exist after the 
update or title changes to unexpected titles. 

Fig. 4 6 is a flowchart of virtual package updating 
following a change in an INDEX . BDMV file. Firstly, when a 



title in Java mode is played (step S121) , virtual filesystem 
unit 38 judges whether a Java application has requested a 
virtual package update (step S122), and if there has been 
a request, virtual filesystem unit 38 receives the request 

5 and performs update preparation (step S123) . At the same time 
as checking whether the file and directory structure are 
correct, virtual filesystem unit 38 judges whether an 
INDEX. BDMV file exists (step S124). If an INDEX. BDMV file 
exists, virtual filesystem unit 38 invalidates the existing 

10 INDEX * BDMV file and validates a new INDEX, BDMV file (step 

5125) , before judging whether a title call has occurred (step 

5126) . A title change from a resident application in the BD 
player or from a Java application is performed with reference 
to the new INDEX . BDMV file validated in step S125. Virtual 

15 filesystem unit 38 performs the updating when a title change 

occurs (step S127) . 

Thus, while virtual package updating is not performed 

until a title change occurs after an update request, the new 

INDEX, BDMV file is made available prior to the title change. 
20 This means that after an update request, the title list 

displayed during a title search will have changed prior to 

a title change occurring. 

Since the user then selects titles based on the altered 

title list, errors resulting from the selection of a title 
25 that will cease to exist after updating can be prevented. 

The virtual package can thus be updated without a problem 

during a title change even if the title structure is altered 

due to the updating. 
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Note that virtual package updating following a change 
in an INDEX . BDMV file may be performed when the BD player 
is rebooted. 

5 Variations 

A playback apparatus pertaining to the present 
invention is described above based on the preferred 
embodiments, although the present invention is of course not 
limited to these embodiments, 

10 The above embodiments are described in relation to a 

playback apparatus whose only function is to play recording 
media, although the present invention is not limited to this. 
For example, the present invention may be a 
recording/playback apparatus with recording and playback 

15 functions. 

Files can be placed in local storage using any kind of 
structure, provided that the correspondence with files on 
BD-ROM targeted for merging is clearly shown. 

In the above embodiments, Java (registered trademark) 

20 is used as the programming language of the virtual machine, 
although programming languages other than Java may be used, 
examples of which include Perl Script, ECMA Script and 
B-Sheli, which is used with UNIX (registered trademark) 
operating systems and the like. 

25 The above embodiments are described in relation to a 

playback apparatus that plays BD-ROM, although of course the 
same effects as above are achieved in the case of requisite 
data on BD-ROM as described in the above embodiments being 
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recorded on a writable optical recording medium. 

Furthermore, the same effects as above are of course 
achieved in the case of requisite data on BD-ROM as described 
in the above embodiments being recorded on a portable 
recording medium other than an optical recording medium {e.g. 
SO card, compact flash etc) > 

INDUSTRIAL APPLICABILITY 

A playback apparatus constituting the present invention 
can be administratively, as well as continuously and 
repeatedly manufactured and retailed in manufacturing 
industries. This playback apparatus is particularly 
applicable in movie and consumer appliance industries that 
pertain to the production of video contents. 
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